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C<l ■ Abstract 

PQ ■ An experimental server for stock trading autonomous agents is presented and made 

■ available, together with an agent shell for swift development. The server, written 

c/5 i in Java, was implemented as proof-of-concept for an agent trade server for a real 

^ ■ financial exchange. 
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2 ! 1 Introduction 
O 



There are always investors seeking to place orders more complicated than 
can be accepted by the software of a financial exchange (F/X) system, re- 
■ gardless of its current level of sophistication. To some of these investors, the 

^ - agent metaphor is a means to implementing combinatorial, temporal, con- 

tingent, or otherwise complex orders. In general, a trading agent is a piece 
of encapsulated software that codes the preferences of its owner. In theoret- 
ical research, trading agents have been used in idealized games [1], artificial 
markets [2], and competitions such as the Trading Agent Competition [3] 
(see http://www.sics.se/tac/). To economists, trading agents are specu- 
lating noise traders (traders with non-rational expectations and potentially 
zero intelligence) [4], often subjected to the Efficient Market Hypothesis and 
the Rational Expectations Hypothesis [5] , since the empirical evidence against 
the accompanying assumptions are directed almost exclusively towards human 
traders [6]. In the system of trading agents we consider, the agents interact 
with the same order book as the human traders (cf. [7]), resulting in a sys- 
tem only slightly more complex than an F/X is today, but a system that is 
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extremely difficult to analyze (cf., e.g., [8]). From an academic perspective, 
the introduction of agents in the actual exchange of real stocks is a formidable 
challenge in that it prompts research in real-time control, agent programming, 
decision analysis, user interaction, privacy, and security. Its theoretical mod- 
els must go beyond agent-based computational finance [9] and agent-based 
computational economics [10], and already simulation studies are highly com- 
plex [11] [12] [13] [14]. From a commercial perspective, the concept is promising 
in that it enables implementation of new services in the service portfolio of 
the F/X. A vast range of commercial efforts have helped renew and refine 
the concept of an electronic F/X, including ambitious liquidity-moving ap- 
proaches, such as OptiMark [15] [16] [17]. This fact notwithstanding, there 
has been no technical platform for real stock trading agent development and 
no special-purpose server generally available. We rectify this matter by mak- 
ing available our documented Java code [18] for such a platform. We have also 
implemented an experimental server for supporting agent trading of stocks, 
an Agent Trade Server (ATS). The conceptual development [19] was initiated 
in 2001 (cf. Fig. 1) in cooperation with OM, the world's largest supplier of 
software to stock exchanges [20], and OM has filed a U.S. patent on the ATS 
concept [21]. The ATS was built not with commercial operation in mind, but 
as proof-of-concept. That said, OM's trading package SAXESS and its third 
party APIs provided for much inspiration. We have not designed the ATS 
for any particular market design. Instead, all agents must abide by the rules 
of the F/X. The submarket emerging from ATS operations will depend on 
the agents' business logic, including their decision-analytic [22] and normative 
modeling [23] of the market, which we have previously investigated. We have 
no illusion of ATS traffic accounting for more than one per cent of any stock 
exchange before 2010, and whether or not investors will find the ATS attrac- 
tive will to a large extent depend on pricing and other commercial or political 
concerns. 

The following section briefly describes the role that software, and agent soft- 
ware in particular, plays at an electronic F/X. In Section 3, the architecture 
of our ATS is explained. In Section 4, the issue of logging and other forms of 
keeping history is highhghted. The various business roles, i.e. those interested 
in the logs, are also discussed. We end with our conclusions and directions for 
future research. 



2 Development of Financial Exchange Software 

Trading of stocks is normally done through a broker, as shown in Fig. 2. The 
trader can be a professional investor, a daytrader, or any other person using 
stocks as a means to invest. The broker could be a bank, an Internet broker, 
or some other financial institution. The figure is simplified: orders can also be 
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Fig. 1. The four phases of the ATS implementation project, with the most fundamen- 
tal at the bottom, and with all four still running. The Gantt schema also indicates 
key breakthroughs in each of the four phases. The second conceptual design will 
hopefully be made at OM, or at some other ITC provider for F/X software, while in 
itself an interesting academic exercise. The first ATS was made publicly available in 
January 2003, but the permission to run agents on the ATS was restricted to select 
agent developers at SICS and at two Swedish universities. These developers came 
up with a first shell in January, which was refined over the following months, and 
sophisticated agents are now under development. As a result of a small empirical 
study, not reported on here, the first user service — a trade notification service for 
smart phones — was recently implemented. 



placed by walking into a bank and filling out a form, IP phones are no require- 
ment, the computer used is often a PDA, etc. Each broker communicates with 
the core of the F/X via a gateway, over leased lines (at Stockholmsborsen, the 
Swedish stock exchange, backed up by an ISDN connection, as well as OMnet^ 
a fibre-optic MetroLAN option). In Fig. 2, the dissemination of information 
from the F/X to the outside world is not shown. Suffice to say here that stock 
exchange dissemination is an elaborate system of latencies and routing, in or- 
der to secure fairness, and that such information is an important part of the 
feedback from core to broker, and from broker to trader. 

Suppliers of software to an electronic exchange system are basically of two 
kinds: those that provide software serving the core (the order book), and those 
that provide software for those interacting with the core (the traders). In most 
countries, the software supplier in the first category is also competing in the 
second category. In Sweden, for example, OM provides all of the software for 
the core, and they also provide the SAXESS and CLICK (for the derivatives 
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Fig. 2. A schematic view of the current trade information flow. For simphcity, dis- 
semination procedures are not shown. 

market, which we will neglect entirely at this stage) software trading packages, 
as well as the SECUR software clearing and back office package. The bulk of 
the software aimed at traders and brokers is however developed by third party 
software houses. We would like to complicate Fig. 2 slightly (see Fig. 3) by 
considering individuals as service provisioners [24], thus introducing a third 
kind of code developer. We anticipate that end-user code development in the 
form of trading agents will be an increasingly important part of the future 
F/X service portfolio. 

The third party code pertains to the trading applications used. In order to 
use the SAXESS system today, the broker needs a member SAXESS trade 
application. Each such application must be certified, to guarantee smooth op- 
eration alongside all other running applications. The OM application offered 
is SAXESS Trade^ an NT-based client-server solution with the trading data 
being maintained on an SQL server. There are currently about two dozen cer- 
tified alternatives. Each application connects to a SAXESS trade server, which 
is in turn connected to the core. The transaction protocol used is XTP (open 
eXchange Transaction Protocol) 2.40, an OSI Layer 7 protocol. The Session 
Layer protocol used is XMP (eXchange Message Protocol). The transactions 
involving the core are governed by a C program, essentially matching the stack 
of sell orders with the stack of buy orders. It is important to note that the 
matching is deterministic. The ATS concept is not a suggested alternative 
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Fig. 3. Three kinds of code development. 

to the SAXESS (or any other) trade server currently in use, but a comple- 
ment. In Fig. 4, the ordinary electronic trading is represented by SAXESS. 
Upward arrows denote the placing of orders while downward arrows denote 
feedback. Each trade application uses zero or more distributed instances of 
the SAXESS Trade Server, a freeware available to all registered traders. In 
practice, the ATS will also contain an instance of the SAXESS Trade Server, 
since the latter contains the latest API for communicating with the core. All 
communication with the core goes via the Front End (FE). The wall indicates 
the physical and logical boundary between the market owner and the outside 
world, while the barbed wire surrounding the core illustrates a further level of 
protection. The shadow backup system is not shown. 

Note that brokers may still be used, for example for legal reasons, when dele- 
gating trading to an agent. While delegating the right to place orders in itself 
does not introduce non-determinism in the marketplace, there is nothing that 
'per se stops an agent developer to introduce non-determinism in the business 
logic of the agent. Security control of agent code is done at the time of agent 
certification and testing, and also online in the ATS. 

In SAXESS, each trade application must also connect to a dedicated Dis- 
tributed Dissemination Server (DDS). With an ATS running together with a 
SAXESS trade server, the owner of the F/X has the option to either route all 
traffic feedback through the existing DDS channels, or to complement the 
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Fig. 4. The ATS as a complement to ordinary electronic trading. 
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DDS with ATS traffic feedback. In particular, the agents running on the 
ATS could subscribe to ATS traffic feedback of various sorts, and at vari- 
able cost. Even non-professional traders are no strangers to varying levels of 
sophistication of the individually specified trading constraints built on feed- 
back. The stop loss service offered by Internet brokers (such as Avanza; see 
: //www . avanza . coin| ) is a case in point. 

The ATS concept provides the third party software houses with a business op- 
portunity, viz. to provide code for the agents trading on the ATS. This involves 
coding investor preferences and encapsulating these into agents, whereafter the 
agents are placed on the ATS, without disclosure. Preference elicitation is as 
always difficult, but suffice to say here that investors will come in many vari- 
eties, from those that have developed advanced agents on their own, to those 
that have no clue on agent programming. A template agent can be coded 
based on the investor filling out a fairly simple questionnaire. The size and 
structure of such template agents is simple, and the first agent shell for our 
ATS has already been written [25]. After the agent is placed on the ATS, 
there remains the challenge of providing software services for notification and 
(depending on security issues) possibly for termination of agents. Investors 
no doubt require interfaces for a variety of modalities, and will in the future 
include roaming [26]. 



3 An Agent Trade Server Architecture 

We developed the ATS in-house at SICS, in order to allow for free experimen- 
tation with agent code and simultaneously adjusting and adding code to the 
server. A jar- file containing an agent can be run locally or remotely. Each trad- 
ing agent executes in its own thread. The three server packages implemented 
(cf. Fig. 5) are described in turn below. The choice of Java was motivated, 
among several factors, by smooth compatibility with small devices, such as 
Java-enabled cell phones. While there is no theoretical reason to limit any 
sandbox environment for agent development to only one language, Java cur- 
rently seems the most practical first choice. For instance, Java's policy files are 
useful for defining the boundary between ATS and agent, and Java, security 
allows for basic signing of agent code. 

3.1 se.sics.ats.core 

This package represents the interface towards the agents, and is distributed to 
agent developers. Initially, the list of agent developers will most likely overlap 
considerably with the list of certified SAXESS members, and the principles 
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Fig. 5. The three ATS packages implemented. 



for testing similar. The next step is then to automate the certification process 
so that individual agent developers can submit agents to the ATS. Since there 
are legal and practical reasons for the market owner not to certify every single 
developer, there is room here for traditional as well as agent brokerage. The 
class AgentComponent specifies all ATS interfacing demands on the agent. For 
instance, the agent must have functionality for starting and stopping. The class 
AgentContext is the agent's handle on the server. AgentContext is inspired 
by and adheres to the SAXESS Trade API for third party code development, 
based on Microsoft's Component Object Model (COM). 



3.2 se. sics. ats. reference 



This package contains the implementation of the ATS itself. It contains log 
handlers and socket tranceivers. 
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3.3 se.sics.ats.data 



This package represents the interface towards the stock exchange. This is 
where the ATS wiU connect to the core of the F/X. For now, it contains 
a parser which, hke the connection, can easily be replaced by another. It 
now parses data disseminated through the WWW (more specifically, it parses 
[http://www.stockholmsborsen.se). The ATS thus uses real stock exchange 
data, albeit with a delay of up to 15 minutes. We have limited its capability 
at the outset to the most traded stocks on the Stockholmsborsen A-list. The 
package also simulates an order book. 



4 Agent Shell Execution 

We can now specify the "Agent" rectangle from Fig. 5 above by explaining the 
agent shell. We first turn to some more abstract aspects of ATS management, 
however. 



Jf..! Roles 

In our proof-of-concept implementation work, we have felt a need for a division 
of labor between agent developers and ourselves: the ATS developers. In order 
to leave the core software unchanged — a requirement from OM, and most likely 
from any market owner — we also need to define the role of ATS administrator. 
The regulation of trade in SAXESS is today done through surveillance of the 
Trading Engine (Sax View), as well as through the official trading control and 
supervisory functions units. These units operate on the core and will be used 
also for agent trading. In addition, the ATS administrator must store and sign 
certificates for authenticated agent code developers. 

In addition, there are new business roles in the future scenario of commer- 
cially available ATS services, perhaps including dedicated agent brokers. We 
have enabled this new business role by implementing an object relating agent 
brokers and their agents. This object maintains references, deducts brokerage 
fees, and supplies data for notification services. For security reasons, the agent 
broker object is placed in the same execution environment as the ATS. The 
only agent manipulation granted the object is the killing of an agent thread, 
should this become necessary. 
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<logfile> 

<status invoked_by= "start" date="20030211" time="14:01:01:239"> 
<portfolio total_value="0-0" /> 
occount value="10000.0" /> 

</status> 

event type="getAsk" date="20030211" time="14:01:01:259"> 
<variable nanne="symbol" value="SICS" /> 
<variable nanne="returned_value" value="100.0" /> 

</event> 

event type="subscribe" date="20030211" time="14:01:01:269"> 
<variable nanne="property" value="SP_ASK" /> 
<variable name="symbol" value="SICS" /> 

</event> 

<event type="property_changed" date="20030211" 
tinne="14:01:18:364"> 
<variable na me =" property" value="SP_ASK" /> 
<variable name="symbor' value="SICS" /> 
<variable name="value" value="101.0" /> 

</event> 

<event type="createOrder" date="20030211" time="14:01:18:374"> 
<variable nanne="order_id" value="OID- 

Daytraderl044968478364" /> 
<variable nanne="property" value="ORDER_TYPE_BID" /> 
<variable nanne="creation_date" value="20030211 

14:01:18:364" /> 
<variable name="price" value="101.0" /> 
<variable name="symbol" value="SICS" /> 
<variable name="quantity" value="10" /> 

</event> 

<event type="enterOrder" date="20030211" time="14:01:18:374"> 
<variable name="order_id" value="OID- 

Daytraderl044968478364" /> 
<variable name="property" value="ORDER_TYPE_BID" /> 
<variable nanne="creation_date" value="20030211 

14:01:18:364" /> 
<variable nanne="price" value="101.0" /> 
<variable nanne="symbol" value="SICS" /> 
<variable nanne="quantity" value="10" /> 

</event> 

<event type="orderClosed" date="20030211" time="14:01:18:384"> 
<variable name="order_id" value="OID- 

Daytraderl044968478364" /> 
<variable name="property" value="ORDER_TYPE_BID" /> 
<variable name="creation_date" value="20030211 

14:01:18:364" /> 
<variable nanne="price" value="101.0" /> 
<variable nanne="symbol" value="SICS" /> 
<variable nanne="quantity" value="10" /> 

</event> 

<event type="getBid" date="20030211" tinne="14:01:18:394"> 
<variable nanne="symbor' value="SICS" /> 
<variable name="returned_value" value="100.0" /> 

</event> 

Fig. 6. Excerpt from a log of Daytrader, a simple agent running on the ATS. 
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4.2 Logs 



The ATS administrator must monitor the actions of aU agents on the ATS, 
and activity logs are therefore needed. These logs are likely to be processed 
only automatically, but in case of system failure or suspected illicit agent ac- 
tion, manual inspection may be required. For this reason, the responsibility 
for logging should not be distributed, but be the responsibility of the ATS 
administrator. Each agent should be allowed read and write access to its own 
action logs, since logs provide interesting information on top of the gener- 
ally available trade statistics. Logged information could be used for machine 
learning, which could occur offline or online, depending on the agent business 
logic. An excerpt from a log of a simple agent, to be discussed further in the 
next subsection, is shown in Fig. 6. The full source code of the agent, as well 
as the full log, has been published [25]. Since all stakeholders are potentially 
interested in parsing the log, it is in XML format. For instance, the ATS ad- 
ministrator might like to find the agent responsible for some illegal action on 
the ATS. Analogously, an agent broker might seek to attribute errors to the 
ATS implementation, using logs as evidence. The error log of Java exceptions 
and String objects is kept separate from all other logged data. 



4-3 se. sics. ats. agent 



The structurally designed agent shell packages are intended as support for ATS 
agent development, and their JavaDoc is publicly available [27]. We give an 
abstract overview here of the low coupling design, so that the role of the shell 
in our implementation of the ATS is made clear. Agents extend the abstract 
TradeAgent class (see Fig. 7), which handles all ATS interaction, including the 
final methods initialize and start, invoked by the ATS [18]. The agent 
(SubAgent) gets information about stocks through various get methods, or by 
subscribing to stock changes (cf. Fig. 6). The latter alternative is the one used 
by most non-artificial stock traders today, and so subscription procedures and 
costs have already been carefully designed at most exchanges. 

Agents place orders using the Order object, and its interface OrderListener [18] 
An order is created by calling the method createOrder. The OrderListener 
then implements the methods orderCancelled and orderClosed, which re- 
sult in account updates and logging, as demonstrated in Fig. 6. The account 
and portfolio maintenance should in any commercial implementation of the 
ATS be handled by standard F/X middleware. Similarly, the AgentBroker 
has only minimal functionality in this version of the ATS. 
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Fig. 7. The agent shell package structure. 
5 Conclusions and Further Research 



We have described a proof-of-concept implementation of a running agent trade 
server, which we believe serves as a blueprint for future implementations in- 
tended for live use on a real financial exchange. We have also constructed and 
described an agent shell, currently in use for server implementation of agents 
of increasing complexity. These agent developers are also providing the first 
anecdotal evidence of the quality of our implementation. We intend to en- 
gage more developers before a formal evaluation is made. Our future work (cf. 
Fig. 1) includes demonstrating that the size of an agent with a sophisticated 
business logic is manageable. We have also implemented various demonstra- 
tors for notifying services, to be used for presenting agent logs to the agent 
brokers and agent owners [28] . While professional trading is a highly collabo- 
rative activity [29] , the agents in our set-up model each other only in a weak 
sense, based solely on their bidding. There are several multi-agent system as- 
pects that deserve attention, such as multiple agent submission for teamwork, 
or even for manipulative purposes. Finally, the effects on the entire financial 
system as a result of wide adoption of agent trade is under investigation. This 
work is being done together with the Stockholm School of Economics and OM. 
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